Natural Language Interfaces to Databases - An Introduction* 



I. Androutsopoulost G.D. Ritchie^ P. Thanisch* 

in 

^Department of Artificial Intelligence, University of Edinburgh 
80 South Bridge, Edinburgh EH1 1HN, Scotland, U.K. 
e-mail: ion@aisb.ed.ac.uk. G.D.Ritchie@ed.ac.uk 



OS 



(N 
> 



^Department of Computer Science, University of Edinburgh 
King's Buildings, Mayfield Road, Edinburgh EH9 3JZ, Scotland, U.K. 

e-mail: pt@dcs.ed.ac.uk 



Abstract 



, This paper is an introduction to natural language interfaces to databases (Nlidbs). 

f*^) ' A brief overview of the history of Nlidbs is first given. Some advantages and disad- 

, vantages of Nlidbs are then discussed, comparing Nlidbs to formal query languages, 

OS ' form-based interfaces, and graphical interfaces. An introduction to some of the linguistic 

(3JT), problems Nlidbs have to confront follows, for the benefit of readers less familiar with 

computational linguistics. The discussion then moves on to Nlidb architectures, porta- 
I- bility issues, restricted natural language input systems (including menu-based Nlidbs), 

and Nlidbs with reasoning capabilities. Some less explored areas of Nlidb research are 
Q , then presented, namely database updates, meta-knowledge questions, temporal questions, 

and multi-modal Nlidbs. The paper ends with reflections on the current state of the art. 

X 

H ' 1 Introduction 

A natural language interface to a database (Nlidb) is a system that allows the user to access 
information stored in a database by typing requests expressed in some natural language (e.g. 
English). The following example is a dialogue between the user and Loqui, a commercially 



available Nlidb |L5| (the dialogue is borrowed from 14]; the system's responses are slightly 
simplified). Throughout this paper messages printed by a Nlidb are shown in this typeface; 
user entries are shown in this typeface. 

> Who works on 3 projects? 

B. Vandecapelle , C. Willems, D. Sedlock, J.L. Binot, L. Debille, ... 

> Which of them are project leaders? 
D. Sedlock, J.L. Binot 

> Documents describing their projects? 
Bim_Loqui: "The Loqui Nlidb", "Bim_Loqui" 
Mmi2: "Technical Annex" 

> How many of these projects do not finish before 1994? 



*To appear in the Journal of Natural Language Engineering, Cambridge University Press. Also available 
as Research Paper no. 709, Department of Artificial Intelligence, University of Edinburgh, 1994. 
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Bim_Loqui, Mmi2 

> Are they led by JLB or DS? 

The former. 

The purpose of this paper is to serve as an introduction to some key concepts, problems, 
methodologies, and lines of research in the area of natural language interfaces to databases. 
This paper is by no means a complete discussion of all the issues that are relevant to Nlidbs. 
The reader is also referred to |29| and |7£| for alternative surveys of the same field.[] A detailed 
description of a natural language front-end that reflects the current state of the art can be 
found in § and §. 

Although the paper contains hints about the capabilities of existing Nlidbs, it does not 
contain complete descriptions of particular systems, nor is the purpose of this paper to com- 
pare particular Nlidbs. This paper is mainly based on information obtained from published 
documents. The authors do not have personal hands-on experience with most of the Nlidbs 
that will be mentioned. Whenever a system's feature is mentioned, this means that the doc- 
uments cited state that the particular system provides this feature, and it is not implied that 
other systems do not have similar capabilities. Finally, this paper assumes that the user's 
requests are communicated to the Nlidb by typing on a computer keyboard. Issues related 
to speech processing are not discussed. 

The remainder of this paper is organised as follows: section ^ is a brief overview of the 
history of Nlidbs^]; section || discusses the advantages and disadvantages of Nlidbs; section || 
presents some of the linguistic problems Nlidbs have to cope with; section [| describes archi- 
tectures adopted in existing Nlidbs; section || discusses portability issues related to Nlidbs; 
section introduces Nlidbs that explicitly restrict the set of natural language expressions the 
user is allowed to input, so that the user can have a clearer view of what sorts of questions the 
system can understand; section |8| describes Nlidbs with reasoning modules; section |9| high- 
lights some less explored areas of Nlidb research, namely database updates, meta-knowledge 
questions, temporal questions, and multi-modal interfaces; finally, section summarises the 
current state of the art. 



2 Some history 

Prototype Nlidbs had already appeared in the late sixties and early seventies. The best- 



known Nlidb of that period is Lunar [106], a natural language interface to a database 



containing chemical analyses of moon rocks. Lunar and other early natural language in- 
terfaces were each built having a particular database in mind, and thus could not be easily 
modified to be used with different databases. (Although the internal representation meth- 
ods used in Lunar were argued to facilitate independence between the database and other 



modules [105], the way that these were used was somewhat specific to that project's needs. 



Portability issues are discussed in section |6[) 

By the late seventies several more Nlidbs had appeared. Rendezvous [27] engaged the 
user in dialogues to help him/her formulate his/her queries. Ladder |58| could be used 
with large databases, and it could be configured to interface to different underlying database 



management systems (Dbmss). Ladder used semantic grammars (discussed in section |5.3| 

1 SectionsJ3 and |B] were greatly influenced by |79|. 

2 Section gis largely based on information from |29| , |T9[ , and ps| ]. 
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a technique that interleaves syntactic and semantic processing. Although semantic grammars 
helped to implement systems with impressive characteristics, the resulting systems proved 
difficult to port to different application domains. Indeed, a different grammar had to be 
developed whenever Ladder was configured for a new application. As researchers started to 
focus on portable Nlidbs, semantic grammars were gradually abandoned. Planes [100] and 
PhiliqaI p2] were some of the other Nlidbs that appeared in the late seventies. 



Chat-80 |101|1 is one of the best-known Nlidbs of the early eighties. Chat-80 was 
implemented entirely in Prolog. It transformed English questions into Prolog expressions, 
which were evaluated against the Prolog database. The code of Chat-80 was circulated 
widely, and formed the basis of several other experimental Nlidbs (e.g. Masque || |7|] ||). 

In the mid-eighties Nlidbs were a very popular area of research, and numerous prototype 
systems were being implemented. A large part of the research of that time was devoted to 
portability issues. For example, Team [47] [48] [^] was designed to be easily configurable by 
database administrators with no knowledge of Nlidbs. 

Ask [92] @ allowed end- users to teach the system new words and concepts at any point 
during the interaction. Ask was actually a complete information management system, pro- 
viding its own built-in database, and the ability to interact with multiple external databases, 
electronic mail programs, and other computer applications. All the applications connected 
to Ask were accessible to the end-user through natural language requests. The user stated 
his/her requests in English, and Ask transparently generated suitable requests to the appro- 
priate underlying systems. 

Janus [|59[ [81] [102] [0] had similar abilities to interface to multiple underlying systems 
(databases, expert systems, graphics devices, etc). All the underlying systems could partici- 
pate in the evaluation of a natural language request, without the user ever becoming aware 
of the heterogeneity of the overall system. Janus is also one of the few systems to support 
temporal questions (discussed in section 9.3). 

Systems that also appeared in the mid-eighties were DATALOG0 |0| ||, EUFID @, LDC 
|] 0, Tqa Q Ijnj, Teli §], and many others. 

Although some of the numerous Nlidbs developed in the mid-eighties demonstrated im- 
pressive characteristics in certain application areas, Nlidbs did not gain the expected rapid 
and wide commercial acceptance. For example, in 1985 Ovum Ltd. ||| (p. 14) was foreseeing 
that "By 1987 a natural language interface should be a standard option for users of Dbms 
and 'Information Centre' type software, and there will be a reasonable choice of alterna- 
tives."^ Since then, several commercially available Nlidbs have appeared, and some of them 
are claimed to be commercially successful. However, Nlidbs are still treated as research or 
exotic systems, rather than a standard option for interfacing to databases, and their use is 
certainly not wide-spread. The development of successful alternatives to Nlidbs, like graph- 
ical and form-based interfaces, and the intrinsic problems of Nlidbs (both discussed in the 
following section) are probably the main reasons for the lack of acceptance of Nlidbs. 

In recent years there has been a significant decrease in the number of papers on Nlidbs 
published per year. Still, Nlidbs continue to evolve, adopting advances in the general natural 
language processing field (e.g. discourse theories - section |8^ ) , exploring architectures that 
transform Nlidbs into reasoning agents (section |sj) , and integrating language and graphics to 
exploit the advantages of both modalities (section |9.4[) , to name some of the lines of current 

3 This Nlidb has nothing to do with the subset of Prolog described in j98|, which is also called Datalog. 
4 A more recent report on natural language markets by the same company is jr7|. 
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research. Generic linguistic front-ends have also appeared. These are general-purpose systems 
that map natural language input to expressions of a logical language (e.g. the Cle system Q 
- see also Q). These generic front-ends can be turned into Nlidbs, by attaching additional 
modules that evaluate the logic expressions against a database (section ||) . The following are 
some of the commercially available Nlidbs: 

• Intellect |5(| from Trinzic (formed by the merger of AlCorp and Aion). This system 



is based on experience from Robot [^] [54] |p5| . 



Bbn's Parlance [12], built on experience from the development of the Rus [16] and 
Irus Jll| systems. 



Ibm's Languageaccess [76]. This system stopped being commercially available in 
October 1992. 

Q&A from Symantec. 

Natural Language from Natural Language Inc. According to [29|, this system was 



previously known as Datatalker, it is described in [72], and it is derived from the 
system described in |46|. 



LOQUI fl5|] from BlM. 



• English Wizard from Linguistic Technology Corporation. The company was founded 
by the author of AlCorp's original Intellect. 

Some aspects of the linguistic capabilities of Intellect, Q&A, and Natural Language 
are reviewed in [S5|. 

It should be noted that when some researchers use the term "database", they often just 
mean "a lot of data". In this paper, we mean quite a lot more than that. Most impor- 
tantly, the data is assumed to represent some coherent attempt to model a part of the world. 
Furthermore, the database is structured according to some model of data, and the Nlidb 
is designed to work with that data model. Database systems have also evolved a lot during 
the last decades. The term "database system" now denotes (at least in computer science) 
much more complex and principled systems than it used to denote in the past. Many of 
the underlying "database systems" of early Nlidbs would not deserve to be called database 
systems with today's standards. 

In the early days of database systems, there was no concept of naive end-users accessing the 
data directly; this was done by an expert programmer writing a special computer program. 
The reason for this was the 'navigational' nature of the data model used by these early 
database systems. Not only did the user need to know about the structure of the data in the 
application. He/she also needed to know many programming tricks to get at the data. The 
development of the relational model of data in the 1970's (Codd [^]) had a major impact on 
database systems. In the relational model, the only storage structure is the table, and this 
was something that even naive users could understand. Relatively simple declarative query 
languages, such as SQL (see section ||), were developed for this class of user. 

Currently, there are two major developments in database technology that will have an 
impact on Nlidbs. The first is the growing importance of object-oriented database systems, 
and the second is the trend in relational database technology towards more complex storage 
structures to facilitate advanced data modelling. We note that both of these trends could 
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make it harder to produce an Nlidb. They both reflect a tendency to concentrate on new 
complex database application areas, such as network management and computer-aided design, 
where the user is anything but naive, and the immediate access to the database will often be 
carried out by a layer of application software. 



3 Advantages Sz. disadvantages 

This section discusses some of the advantages and disadvantages of Nlidbs, comparing them 
to formal query languages, form-based interfaces, and graphical interfaces. 

Access to the information stored in a database has traditionally been achieved using 



formal query languages, such as SQL (see [98] for an introduction to Sql). Let us assume, for 



example, that the following tables are stored in a relational database: 

employees_table departments-table 
employee department phone department manager city 



Thompson sales 2317 sales Ferguson London 

Richardson accounting 2554 accounting Richardson Bristol 

The first table, employees_table, shows the department and phone number of each em- 
ployee. The second table, departments_table, shows the manager of each department, and 
the city where each department is located. A list showing each employee's manager can be 
created using the Sql query: 

SELECT employees_table . employee , departments_table .manager 
FROM employeesjtable , departments_table 

WHERE employeesjtable . department = departments_table . department 

The SQL query above instructs the database system to report all possible pairs consisting 
of an employee value and a manager value, such that the employee value comes from a row 
in employees_table, the manager value comes from a row in departments_table, and the two 
rows have the same department value. 

In form-based interfaces (e.g. |80[| ), pre-defined forms consisting of fields are used. The 
user fills the information which is already known in the corresponding fields, and the system 
completes the remaining fields by querying the underlying database. A user wishing to learn 
the manager of an employee named "Thompson" could fill in the pre-defined form "Employee 
Information Form" as shown below on the left. The system would respond by filling the 
remaining fields as shown below on the right. 

Employee Information Form Employee Information Form 



Employee: Thompson Employee: Thompson 

Department : Department : sales 

Phone: Phone: 2317 

Manager: Manager: Ferguson 

If there are two or more answers (e.g. more than one employee called "Thompson"), the 
system responds by generating a stack of filled forms, one form per possible answer. 

In a more powerful method, called query by example (proposed by Zloof, see (9^] for a 
description), the user can combine an arbitrary number of forms, where each form reflects 
the structure of a database table. The manager of "Thompson" could be found using the 
following query- by-example forms: 
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employee s_table 




departments_table 




employee : Thompson 


department: < 




department: < 






manager: ? 


phone: 


city: 













Figure 1: A graphical query 



employeesjtable jform department s_table_f orm 

employee department phone department manager city 



Thompson X X P.Y 



The first form shows that the system should select from employees_table rows having Thomp- 
son as employee value. The two occurrences of variable X show that each row selected from 
employees_table should be joined with rows from departments_table that have the same de- 
partment values. The P.Y entry shows that the corresponding manager value is to be printed. 
Finally, in one approach to graphical interfaces (similar to the one used in SunSimplify 



[87 1) the user first selects the database tables to be used in the query (employee-table and 
manager stable in our example). Each selected table appears on the screen as a frame con- 
sisting of attribute-slots. The user can then fill in attribute slots by typing on the keyboard, 
he/she can join attributes across the various frames using the mouse, or he/she can impose 
restrictions on attributes using the mouse and menu options. To find the manager of "Thomp- 
son", a user could use the graphical query shown in figure [l]. A similar method is to allow 
frames to correspond to world entities (e.g. managers, employees, departments), rather than 
to database tables. 

The following advantages and disadvantages of Nlidbs are often mentioned in the litera- 
ture. 



Some advantages of NLIDBs 

No artificial language: One advantage of Nlidbs is supposed to be that the user is not 
required to learn an artificial communication language. Formal query languages are difficult to 
learn and master, at least by non-computer-specialists. Graphical interfaces and form-based 
interfaces are easier to use by occasional users; still, invoking forms, linking frames, selecting 
restrictions from menus, etc. constitute artificial communication languages, that have to be 
learned and mastered by the end-user. In contrast, an ideal Nlidb would allow queries to 
be formulated in the user's native language. This means that an ideal Nlidb would be more 
suitable for occasional users, since there would be no need for the user to spend time learning 
the system's communication language. 

In practice, current Nlidbs can only understand limited subsets of natural language. 
Therefore, some training is still needed to teach the end-user what kinds of questions the 
Nlidb can or cannot understand. In some cases, it may be more difficult to understand what 
sort of questions an Nlidb can or cannot understand, than to learn how to use a formal query 
language, a form-based interface, or a graphical interface (see disadvantages below). One may 
also argue that a subset of natural language is no longer a natural language. 
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Better for some questions: It has been argued (e.g. pq| ) that there are kinds of questions 
(e.g. questions involving negation, or quantification) that can be easily expressed in natural 
language, but that seem difficult (or at least tedious) to express using graphical or form-based 
interfaces. For example, "Which department has no programmers?" (negation), or "Which 
company supplies every department?" (universal quantification), can be easily expressed in 
natural language, but they would be difficult to express in most graphical or form-based 
interfaces. Questions like the above can, of course, be expressed in database query languages 
like Sql, but complex database query language expressions may have to be written. 



Discourse: Another advantage of Nlidbs, mentioned in |37]] and |28|| , concerns natural 
language interfaces that support anaphoric and elliptical expressions (sections [4.5| and 4.6). 
Nlidbs of this kind allow the use of very brief, underspecified questions, where the meaning of 
each question is complemented by the discourse context. In formal query languages, graphical 
interfaces, and form-based interfaces this notion of discourse context is usually not supported. 
This point will become clearer in sections 4.5 and 4.6. 



Some disadvantages of NLIDBs 

Linguistic coverage not obvious: A frequent complaint against Nlidbs is that the sys- 



tem's linguistic capabilities are not obvious to the user Q |37]] | 2q| . As already mentioned, 
current Nlidbs can only cope with limited subsets of natural language. Users find it difficult 
to understand (and remember) what kinds of questions the Nlidb can or cannot cope with. 
For example, Masque |7j is able to understand "What are the capitals of the countries bor- 
dering the Baltic and bordering Sweden?" , which leads the user to assume that the system can 
handle all kinds of conjunctions (false positive expectation). However, the question "What 
are the capitals of the countries bordering the Baltic and Sweden?" cannot be handled. Simi- 
larly, a failure to answer a particular query can lead the user to assume that "equally difficult" 
queries cannot be answered, while in fact they can be answered (false negative expectation). 

Formal query languages, form-based interfaces, and graphical interfaces typically do not 
suffer from these problems. In the case of formal query languages, the syntax of the query 
language is usually well-documented, and any syntactically correct query is guaranteed to be 
given an answer. In the case of form-based and graphical interfaces, the user can usually 
understand what sorts of questions can be input, by browsing the options offered on the 
screen; and any query that can be input is guaranteed to be given an answer. 



Linguistic vs. conceptual failures: When the Nlidb cannot understand a question, it 
is often not clear to the user whether the rejected question is outside the system's linguistic 
coverage, or whether it is outside the system's conceptual coverage [90]. Thus, users often 
try to rephrase questions referring to concepts the system does not know (e.g. rephrasing 
questions about salaries towards a system that knows nothing about salaries), because they 
think that the problem is caused by the system's limited linguistic coverage. In other cases, 
users do not try to rephrase questions the system could conceptually handle, because they do 
not realise that the particular phrasing of the question is outside the linguistic coverage, and 
that an alternative phrasing of the same question could be answered. Some Nlidbs attempt 
to solve this problem by providing diagnostic messages, showing the reason a question cannot 
be handled (e.g. unknown word, syntax too complex, unknown concept, etc.) (see section 
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Users assume intelligence: As pointed out in |57[| , Nlidb users are often misled by the 
system's ability to process natural language, and they assume that the system is intelligent, 
that it has common sense, or that it can deduce facts, while in fact most Nlidbs have 
no reasoning abilities (see however section ||). This problem does not arise in formal query 
languages, form-based interfaces, and graphical interfaces, where the capabilities of the system 
are more obvious to the user. 



Inappropriate medium: As mentioned in Pq| , it has been argued that natural language 
is not an appropriate medium for communicating with a computer system. Natural language 
is claimed to be too verbose or too ambiguous for human-computer interaction. Nlidb users 
have to type long questions, while in form-based interfaces only fields have to be filled in, and 
in graphical interfaces most of the work can be done by mouse-clicking. Natural language 
questions are also often ambiguous, while formal, form-based, or graphical queries never have 
multiple meanings. Section |] presents some of the problems in this area, and discusses how 
Nlidbs attempt to address them. 



Tedious configuration: Nlidbs usually require tedious and lengthy configuration phases 
before they can be used (see section ^). In contrast, most commercial database systems have 
built-in formal query language interpreters, and the implementation of form-based interfaces 
is largely automated. 

Several experiments have been carried out, comparing how users cope with formal query 
languages, form-based interfaces, graphical interfaces, and Nlidbs. 



[13 1 describes one such experiment, during which fifty five subjects, ranging from computer 
novices to programmers, were asked to perform database queries using a formal query language 
(Sql), a graphical interface (SunSimplify - see section |3|), and a Nlidb (Datatalker, later 
known as Natural Language - see section |2|). The subjects first received some training 
on how to use the three interfaces, and were then asked to perform database queries, most 
of which were similar to the queries the subjects had encountered during the training period. 
The experiment measured the number of queries the subjects managed to perform successfully, 
and the average time the subjects used to perform each successful query. None of the three 
interfaces could be said to be a winner. Each interface was better in some kinds of queries, and 
in most queries the subjects' performance was roughly the same, whether the subjects were 
asked to use Sql, the graphical interface, or the Nlidb. Roughly speaking, the Nlidb seemed 
to be better in queries where data from many tables had to be combined, and in queries that 
were not similar to the ones the users had encountered during the training period. Information 



about similar experiments can be found in [62] and [86] 



[|103[[ discusses various approaches that have been used in the evaluation of natural lan- 
guage systems, and describes an experiment where first a Wizard of Oz was used to collect 
sample user questions, and then the sample questions were used as input to an actual Nlidb. 
In a Wizard of Oz experiment, the user interacts with a person who pretends to be an Nlidb 
through a computer network. The user is not aware that he/she is not interacting with a real 
Nlidb. WM provides a set of questions towards a Nlidb that was collected using a Wizard 



of Oz experiment. [37] describes in detail a Wizard of Oz experiment. 

[ 18 1 provides information about several experiments on the usability of Nlidbs, and de- 
scribes in detail one such experiment that assessed the usability of Intellect (see section 
0). The authors conclude that "natural language is an effective method of interaction for 
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casual users with a good knowledge of the database, who perform question- answering tasks, in 
a restricted domain" . [^] also describes an experiment on the usability of Intellect, and 
concludes that Nlidbs are a practical alternative. 



4 Linguistic problems 

This section presents some of the linguistic problems a Nlidb has to confront when attempting 
to interpret a natural language request. Most of these problems do not arise only in Nlidbs; 
they are common in most kinds of natural language understanding systems. It is stressed that 
this section is by no means a full list of the linguistic problems Nlidbs have to confront. This 
section merely presents some of the problems, mainly for the benefit of readers not familiar 
with computational linguistics. 

The reader is reminded that messages generated by the Nlidb are printed in this 
typeface, and that user entries are printed in this typeface. 



4.1 Modifier attachment 

Let us consider the request "List all employees in the company with a driving licence". Lin- 
guistically, both "in the company" and "with a driving licence" are modifiers, i.e. they modify 
the meaning of other syntactic constituents. The problem is to identify the constituent to 
which each modifier has to be attached. 

A human would immediately understand that "in the company" refers to "employees", 
and that "with a driving licence" refers to the "employees in the company". This reading of 
the request corresponds to the structure: 

List all [ [employees [in the company]] [with a driving licence] ]. 

and can be paraphrased as "From the employees working in the company, list those having a 
driving licence". However, a computer system would also consider the following reading: 

List all [employees [in the [company [with a driving licence]]]]. 

where "with a driving licence" refers to the "company". The latter reading can be paraphrased 
as "List all employees working in the company which has a driving licence". This second 
reading cannot be easily ruled out. For example, in the similar request "List all employees in 
the company with an export licence. ", it is the second reading that probably has to be chosen 
( "with an export licence" refers to "the company"). To be able to choose the correct reading, 
the system must know that in the particular application domain employees can have driving 
licences but not export licences, and that companies can have export licences but not driving 
licences. 

Alternatively, some systems attempt to resolve modifier attachment ambiguities by using 
heuristics. Pre [Q uses a "most right association principle" to resolve relative clauses at- 
tachment: relative clauses are assumed to modify the rightmost available constituent. For 
example, in "List an employee who was hired by a recruiter whose salary is greater than 
$3,000.", the relative clause "whose salary is greater than $3,000" is assumed to refer to the 
"recruiter", not the "employee". More advanced disambiguation techniques for prepositional 



phrase attachment can be found in 104 1. 



Still, in some cases modifier attachment is truly ambiguous. Consider the request (bor- 
rowed from (7^]) "List all employees in the division making shoes". In some application 
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domains "making shoes" may equally well refer to the "division" or to the "employees". In 
such CELS6S, cl Nlidb can (a) present to the user paraphrases of both readings, and ask the 
user to chose one of the readings, or (b) it can print answers corresponding to both readings, 
indicating which answers refer to which readings. 

4.2 Quantifier scoping 

Determiners like "a", "each", "all", "some" are usually mapped to logic quantifiers. In cases 
of sentences with many words of this kind, it is difficult to determine which quantifier should 
be given a wider scope. Let us consider the question "Has every student taken some course?". 
The question has two readings, (student and course are variables.) 

1. Check that 

V student 3course taken(student, course) 

2. Check that 

3course V 'student taken(student, course) 

In the first reading, each student is allowed to have taken a different course, while in the 
second reading all students must have taken the same course. 

A possible heuristic method to resolve scoping ambiguities is to prefer scopings pre- 
serving the left-to-right order of the quantifiers. In "Has every student taken some course?", 
"every" appears before "some". Therefore, according to the heuristic, the first of the read- 
ings above should be preferred, since in this reading the universal quantifier introduced by 
"every", precedes the existential quantifier introduced by "some". 



Another approach [79] is to associate a numeric strength to each determiner. In this ap- 
proach, determiners with greater strengths are given wider scopes. Returning to the question 
"Has every student taken some course?", if the strength of "every" is greater than the strength 
of "some", then the first reading is again preferred. The reader is referred to chapter 8 of 0| 
for a detailed discussion of methods that can be used to resolve quantifier scoping problems. 

4.3 Conjunction and disjunction 

The word "and" is often used to denote disjunction rather than conjunction. This introduces 



ambiguities which are difficult to resolve. The following two examples, borrowed from |89|, 
illustrate the problem: 

In "List all applicants who live in California and Arizona." every applicant who lives 
either in California or Arizona should be reported. The possibility for "and" to denote a 
conjunction should be ruled out, since an applicant cannot normally live in more than one 
state. Eufid [B9| detects cases where it is conceptually impossible for "and" to denote a 



conjunction, and turns "and"s to "or"s. (Section 4.2 of |)9| describes a heuristic rule for 
detecting cases where "and" cannot have a conjunctive meaning.) 

"Which minority and female applicants know Fortran?", however, could mean either 
"Which female applicants belonging to a minority know Fortran?" or "Which applicants 
who are female or belong to a minority know Fortran?" . In such cases "and" is truly ambigu- 
ous. 

As in the case of Eufid, when asked "How many people live in Belmont and Boston?", 
Parlance understands that "and" cannot denote a conjunction, and reports the popu- 
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lation of each city. In contrast, when asked "What's the average salary of blacks and hispan- 
ics?", Parlance provides answers corresponding to both possible meanings, by generating 
the following tables: 

Average Salary Ethnic Group Count Average Salary Count 
$42,481.81 Black IT $43,790.47 21 

$45,230.00 Hispanic 10 

4.4 The nominal compound problem 

In English, nouns are often modified by other preceding nouns. The meaning of the resulting 
compound constituent is hard to predict. The following examples, based on examples from 
J79|, illustrate the problem: 

• "city department" could denote a department located in a city, or a department respon- 
sible for a city. 

• "research department" is probably a department carrying out research. 

• "research system" is probably a system used in research, it is not a system carrying out 
research. 

Similar difficulties arise in the case of adjective-noun compounds. For example, a "large 
company" may be a company with a large volume of sales or a company with many employees, 
a "big department" may be a department with many employees or a department occupying 
a lot of space, etc. 

Because of the difficulty in determining the meaning of noun-noun and adjective-noun com- 
pounds from the meanings of the individual compounded nouns or adjectives, some Nlidbs 
require the meaning of each possible noun-noun or adjective-noun compound to be declared 
during the configuration phase (see section |6|). In Ldc-1 || |TIJ, for example, whenever the 
system is taught a new noun (e.g. "department"), the configurer is asked for all adjectives 
(e.g. "large", "small", "profitable") and nouns (e.g. "sales", "city") that can precede the 
new noun as modifiers. The configurer is then asked to define the meaning of each possible 
compound ( "large department", "profitable department" , "sales department", etc.) in terms 
of concepts of the underlying database. 

4.5 Anaphora 

Pronouns (e.g. "she", "they"), possessive determiners (e.g. "his", "their"), and noun phrases 
(e.g. "the project", "these people") are often used to denote implicitly entities mentioned 
in the discourse, a linguistic phenomenon called anaphora. Consider the following dialogue 
between the user and Ask from [p2|]: 

> Is there a ship whose destination is unknown? 
yes 

> What is it? 

What is [the ship whose destination is unknown]? 
Saratoga 

Ask has understood that "it" refers to "the ship whose destination is unknown". Ask echoes 
back the user's question, with the pronoun replaced by what the system understands to be 



11 



its meaning. This prevents the user from being misled, in cases where the pronoun anaphora 
is not resolved correctly. 

The following is a (shortened) dialogue with LOQUI from [14]: 

> Who leads TP I? 
E. Feron 

> Who reports to him? 

C. Leonard, C. Willems, E. Bidonnet, P. Cayphas, J. P. Van Loo 

> What do they work on? 
project worker 



DOCDIS C. Willems 

J. P. Van Loo 

P . Cayphas 
EURS C. Leonard 

C. Willems 

E. Bidonnet 

> Which of these are leaders? 
J. P. Van Loo 

A simplistic method to handle pronoun anaphora is to keep a list of all entities mentioned 
in the discourse. When a pronoun is encountered, the system examines the list, usually 
starting from the most recent entries, and associates each pronoun with the most recently 
mentioned entity that satisfies grammatic and semantic constraints. 

In "Who reports to him?" above, a system could reason that "him" refers to "E. Feron" 
rather than to the project 'Tpi", because the pronoun is of masculine gender, while a project 
is of neutral gender. In "Which of these are leaders?" above, Loqui has probably reasoned 
that "these" refers to the people mentioned in the previous response, rather than to the 
projects mentioned in the previous response, using information stating that only persons not 
projects can be leaders. 

Possessive determiner anaphora (e.g. "their") is similar to pronoun anaphora. The fol- 
lowing example is also from [14]: 

> Who reports to MM? 
E. Feron, J.L. Binot 

> What are their projects? 
project person 
BlM_LOQUl J.L. Binot 
EURS E. Feron 

Noun phrases can also be used as anaphoric expressions. In the following dialogue, from 
"the project" is an anaphoric noun phrase referring to the project "Mmi2": 

> Who leads Mmi2? 
J.L. Binot 

> Who works on the project? 

B. Vandecapelle , D. Sedlock, F. Balfroid, J.L. Binot, L. Debille 



Anaphora is a well-known problem in natural language processing. See [6C] for an overview 
of the issues, and for relatively simple methods that can be used to resolve many cases 
of pronoun anaphora. 
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4.6 Elliptical sentences 



In every-day discourse people use incomplete (elliptical) sentences, the meaning of which is 
complemented by the discourse context. This phenomenon is illustrated in the following 
dialogue (from [12]) between the user and Parlance : 

> Does the highest paid female manager have any degrees from Harvard? 
Yes, 1. 

> How about MlT? 
No, none. 

> Who is the manager of the largest department? 
Name Dept . Count 

Patterson 045 40 

> The smallest department? 
Name Dept . Count 
Saavedra Oil 2 

"How about Mit?" and "The smallest department?" are elliptical sentences. 

Handling complex cases of elliptical sentences requires a discourse model to be maintained 
by the system (see section jjQ| ). Xcalibur [19] uses a set of "discourse expectation" and 
"contextual substitution" rules, that allow elliptical utterances, such as the ones shown below, 
to be understood: 

> What is the price of the three largest single port fixed media disks? 

> speed? 

> two smallest? 

> How about the price of the two smallest? 

> Also the smallest with two ports? 

> speed with two ports? 

The handling of elliptical sentences is a desirable feature in a Nlidb. Nlidb users typically 
do not have single stand-alone questions to ask. The first, often exploratory query, is usually 
followed by many elliptical follow-up queries. Some Nlidbs (e.g. Chat-80 pi) are oriented 
towards the processing of stand-alone questions, providing no support for elliptical questions. 
In such systems, the questions shown above would have to be formulated as: 

> What is the price of the three largest single port fixed media disks? 

> What is the speed of the three largest single port fixed media disks? 

> What is the speed of the two smallest single port fixed media disks? 

> What is the price of the two smallest single port fixed media disks? 

> What is the price of the two smallest fixed media disks with two ports? 

> What is the speed of the two smallest fixed media disks with two ports? 

Having to type every question in full can be annoying for the user, though the problem can 
be alleviated by providing a facility for editing previously entered questions. 



4.7 Extragrammatical utterances 

Most linguistic theories describe the structure and meaning of grammatical, perfectly formed 
utterances. However, every-day language often contains misspellings, syntactically ill-formed 
input, telegraphic utterances, etc. If the main goal of a Nlidb is to assist the user, then 
the system must be able to understand the user's requests, even when they are partially 
ill- formed. 
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Most of the existing Nlidbs can handle only simple cases of extragrammatical utterances. 
For example, Parlance forgives dropped articles, sentences where subject and verb cases or 
numbers do not agree, capitalisation errors and punctuation errors jL2|. It is, thus, able to 
understand sentences like "whats reynolds departments name", or "people in dePT 45 who 
is supervisory scientist". Ask uses its dictionary to correct spelling errors and errors caused 
by missing spaces [^]. In "What is the crago of the Orient Clipper?" it converts "crago" to 
"cargo", and in "What is the cargoof the Orient Clipper?" it converts "cargoof" to "cargo 
of". 

5 Architectures 

5.1 Pattern- matching systems 

Some of the early Nlidbs relied on pattern-matching techniques to answer the user's ques- 
tions. To illustrate a simplistic pattern-matching approach, consider a database table holding 
information about countries: 

countriesjtable 
Country Capital Language 
France Paris French 
Italy Rome Italian 

A primitive pattern-matching system could use rules like: 
pattern: . . . "capital" . . . <country> 

action : Report Capital of row where Country = <country> 

pattern: . . . "capital" . . . "country" 

action : Report Capital and Country of each row 

The first rule says that if a user's request contains the word "capital" followed by a country 
name (i.e. a name appearing in the Country column), then the system should locate the 
row which contains the country name, and print the corresponding capital. 

If, for example, the user typed "What is the capital of Italy?", the system would use the 
first pattern-rule, and report "Rome" . The same rule would allow the system to handle "Print 
the capital of Italy", "Could you please tell me what is the capital of Italy?", etc. In all cases 
the same response would have been generated. 

According to the second rule, any user request containing the word "capital" followed by 
the word "country" should be handled by printing the capital of each country, as listed in 
the database table. For example, "What is the capital of each country?", "List the capital of 
every country", "Capital and country please.", etc., would all be handled by the second rule. 

The main advantage of the pattern-matching approach is its simplicity: no elaborate 
parsing and interpretation modules (see later sections) are needed, and the systems are easy to 
implement. Also, pattern-matching systems often manage to come up with some reasonable 
answer, even if the input is out of the range of sentences the patterns were designed to 
handle. Returning to the example above, the second rule would allow the system to answer 
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which rock 



contains magnesium 



Figure 2: Parse tree in a syntax-based system 



the question "Is it true that the capital of each country is Athens?", by listing the capital of 
each country, which can be considered as an indirect negative answer. 

Pattern-matching systems are not necessarily based on such simplistic techniques as the 
ones discussed above. Savvy, a pattern matching system discussed in [Q (p. 153), employs 
pattern-matching techniques similar to the ones used in signal processing. 

According to |33|, some pattern-matching systems were able to perform impressively well 
in certain applications. However, the shallowness of the pattern-matching approach would 
often lead to bad failures. In one case (mentioned in when a pattern- matching Nlidb 

was asked "titles of employees in LOS Angeles.", the system reported the state where 
each employee worked, because it took "in" to denote the post code of Indiana, and assumed 
that the question was about employees and states. 



5.2 Syntax-based systems 

In syntax-based systems the user's question is parsed (i.e. analysed syntactically), and the 
resulting parse tree is directly mapped to an expression in some database query language. A 



typical example of this approach is Lunar [106]. 



s 


-» NP VP 


NP - 


-» DetN 


Det - 


-» "what" | "which" 


N - 


-> "rock" "specimen" 


VP - 


-> V N 


V 


-» "contains" "emits" 



Syntax-based systems use a grammar that describes the possible syntactic structures of 
the user's questions. The following example, based on a similar example from [jf9| ], shows an 
over-simplistic grammar in a LuNAR-like system. 



"magnesium" \ "radiation" \ "light" 



The grammar above says that a sentence (S) consists of a noun phrase (NP) followed by 
a verb phrase (VP), that a noun phrase consists of a determiner (Det) followed by a noun 
(N), that a determiner may be "what" or "which", etc. Using this grammar, a Nlidb could 
figure out that the syntactic structure of the question "which rock contains magnesium" is as 
shown in the parse tree of figure |2[ The Nlidb could then map the parse tree of figure Q to 
the following database query (X is a variable): 

(for_every X (is_rock X) 

(contains X magnesium) ; 
(printout X) ) 
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S — > Specimen-question \ Spacecraft-question 

Specimen-question — > Specimen Emits -info \ Specimen Contains -info 

Specimen — > "which rock" \ "which specimen" 

Emits-info — > "emits" Radiation 

Radiation — > "radiation" \ "light" 

ContainsJnfo — > "contains" Substance 

Substance — y "magnesium" \ "calcium" 

Spacecraft-question — > Spacecraft DepartSnfo \ Spacecraft ArriveSnf o 
Spacecraft — > "wiich vessel" \ "which spacecraft" 
DepartJnfo — > "was launched on" Date \ "departed on" Date 
Arrive-in fo —y "returns on" Date | "arrives on" Date 

Figure 3: A semantic grammar 

which would then be evaluated by the underlying database system. This mapping would be 
carried out by rules, and would be completely based on the syntactic information of the parse 
tree. The system of our example could use mapping rules stating that: 

• The mapping of "which" is f or_every X. 

• The mapping of "rock" is (is_rock X). 

• The mapping of an NP is Det' N', where Det' and N' are the mappings of the determiner 
and the noun respectively. Thus, the mapping of the NP subtree in our example is 
for_every X (is_rock X). 

• The mapping of "contains" is contains. 

• The mapping of "magnesium" is magnesium. 

• The mapping of a VP is ( V X N') , where V is the mapping of the verb, and N' is the 
mapping of the noun-sister of the verb. Thus, the mapping of the VP subtree in our 
example is (contains X magnesium). 

• The mapping of an S is (NP' VP' ; (printout X) ), where NP' , VP' are the mappings 
of the NP and VP subtree accordingly. Thus, in our example, the mapping of the 
sentence is as shown above. 

Syntax-based Nlidbs usually interface to application-specific database systems, that pro- 
vide database query languages carefully designed to facilitate the mapping from the parse 
tree to the database query. It is usually difficult to devise mapping rules that will transform 
directly the parse tree into some expression in a real-life database query language (e.g. Sql). 

5.3 Semantic grammar systems 

In semantic grammar systems, the question-answering is still done by parsing the input and 
mapping the parse tree to a database query. The difference, in this case, is that the gram- 
mar's categories (i.e. the non-leaf nodes that will appear in the parse tree) do not necessarily 
correspond to syntactic concepts. Figure || shows a possible semantic grammar. 
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s 

Specimen_question 




Specimen_spec Contains_info 




which rock contains Substance 



magnesium 

Figure 4: Parse tree in a semantic grammar 



The reader will have noticed that some of the categories of the grammar of figure || 
(e.g. Substance, Radiation, Specimen_question) do not correspond to syntactic constituents 
(e.g. noun-phrase, noun, sentence). Semantic information about the knowledge domain (e.g. 
that a question may either refer to specimens or spacecrafts) is hard-wired into the semantic 
grammar. Semantic grammar categories are usually chosen to enforce semantic constraints. 
For example, the grammar above does not allow "light" to follow the verb "contains". (In 
contrast, the grammar of the previous section allows "contains light".) 

The grammar's categories can also be chosen to facilitate the mapping from the parse 
tree to database objects. For example, in the parse tree for "which rock contains magne- 
sium", shown in figure the existence of a Specimen_question node could direct the system 
to consult database tables containing information about specimens, rather than tables con- 
taining information about departures and arrivals. Similarly, the Contains_inf o subtree 
could direct the system to search a table called Contains_inf o, and locate the rows of which 
the Substance column is "magnesium". According to [79|, semantic grammars are used in 
Planes |100(|, Ladder pi, and Rel pi p|. A semantic grammar is also used in Eufid 



Hi- 
Semantic grammars were introduced as an engineering methodology, which allows seman- 
tic knowledge to be easily included in the system. However, since semantic grammars contain 
hard-wired knowledge about a specific knowledge domain, systems based on this approach 
are very difficult to port to other knowledge domains (see section ^): a new semantic gram- 
mar has to be written whenever the Nlidb is configured for a new knowledge domain. For 
example, the semantic grammar of figure |3] is completely useless in an application where the 
database contains information about employees and salaries. In contrast, (at least) some of 
the information of the grammar in the previous section (e.g. that a sentence consists of a 
noun phrase followed by a verb phrase) could probably still be used in an application where 
the questions refer to employees and their salaries. 



5.4 Intermediate representation languages 

Most current Nlidbs first transform the natural language question into an intermediate logical 
query, expressed in some internal meaning representation language. The intermediate logical 
query expresses the meaning of the user's question in terms of high level world concepts, 
which are independent of the database structure. The logical query is then translated to an 
expression in the database's query language, and evaluated against the database. Actually, 
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Figure 5: Possible architecture of intermediate representation language system 



many modern natural language front-ends (e.g. Cle [g]) use several intermediate meaning 
representation languages, not just one. 

Figure || shows a possible architecture of an intermediate representation language system. 
A similar architecture is used in Masque/sql H jq]. The natural language input is first 
processed syntactically by the parser. The parser consults a set of syntax rules, and generates 
a parse tree, similar to the one shown in figure |2[ (The reader is referred to [42] for information 
on parsing techniques.) The semantic interpreter subsequently transforms the parse tree to 
the intermediate logic query, using semantic rules similar to the mapping rules of section 5.2. 



Some systems (e.g. Janus |59|]) build on the Montague-semantics tradition [71] [38|, and 
carry out the semantic interpretation in a compositional, rule-to-rule manner. Each syntax 
rule is coupled to a semantics rule. The semantics rule computes the logic expression of the 
constituent in the left-hand side of the syntax rule, as a function of the logic expressions of 
the constituents in the right-hand side of the syntax rule. The logic expressions corresponding 
to words are declared in the lexicon. 

In early Nlidbs the syntax/semantics rules were based on rather ad hoc ideas, and ex- 
pressed in idiosyncratic formalisms. In modern systems the syntax/semantics rules are be- 
coming increasingly influenced by principled linguistic theories, and they are often expressed 
in variations of well-known formalisms. LOQUI [15], for example, uses a grammar influenced 
by Gpsg B3] , and Cle's Q grammar is expressed in a unification-based formalism similar to 
Patr-II fsf . 

In many systems the syntax rules linking non-terminal symbols (non-leaf nodes in the 
parse tree) and the corresponding semantic rules are domain- independent; i.e. they can be 
used in any application domain. The information, however, describing the possible words (leaf 
nodes) and the logic expressions corresponding to the possible words is domain-dependent, 
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Figure 6: A hierarchy in a world model 



and has to be declared in the lexicon. 

In Masque || Q, for example, the lexicon lists the possible forms of the words that 
may appear in the user's questions (e.g. "capital", "capitals", "border", "borders", "bor- 
dering", "bordered"), and logic expressions describing the meaning of each word. For ex- 
ample, the logic expression of "capital" (as in "What is the capital of Italy?") could be 
capital _of (Capital, Country), where Capital is a variable standing for a capital, and Country 
is a variable standing for the corresponding country. 

Similarly, the logic expression of the verb "to border" (as in "Which countries border 
Germany?") could be border s(Country\,Country<2), and the logic expression of the noun 
"country" (as in "Italy is a country") could be is-country (Country). 

The semantic interpretation module uses the logic expressions of the words in the lexicon, 
to generate the logical query. For example, in Masque, the question "What is the capital of 
each country bordering Greece?" would be mapped to the following logical query. (Variable 
names start with capital letters.) 

answer ( [Capital , Country] ) : - 
is_country (Country) , 
borders (Country , greece) , 
capital_of (Capital , Country). 

The logic query above states that the meaning of the user's question is to find all pairs 
[Capital, Country] , such that Country is a country, Country borders Greece, and Capital 
is the capital of Country. The reader will have noticed that the logical query was constructed 
using the logic expressions of "capital", "country", and "to border". 

The semantic interpreter of figure [| also consults a world model, that describes the struc- 
ture of the surrounding world. Typically, the world model contains a hierarchy of classes 
of world objects, and constraints on the types of arguments each logic predicate may have. 
Figure |6| shows a world-model hierarchy of MASQUE, for a business application. Similar hier- 
archies are used in Team [47| ji^] and Cle ||. The hierarchy of figure ^ states that, in the 



particular application domain, a person can be either a client or an employee, that employees 
are divided into technicians, salespersons, and managers, etc. The hierarchy is typically used 
in combination with constraints on predicate arguments. These constraints specify the classes 
to which the arguments of a logic predicate may belong. 

To illustrate the need for predicate-argument constraints, let us consider the business 
application of figure |(| and let us assume that the underlying database holds information 
about the salaries of employees, but that it does not hold information about the salaries of 
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people not employed by the company. (Let us also assume that an employee cannot also 
be a client of the company.) Then, the question "What is the salary of each client?" will 
retrieve no information, because the database does not contain information about the salaries 
of clients. We would like the Nlidb to be able to detect that the question is conceptually 
problematic. 

Let us assume that the logic expression of "salary" is salaryjof (Salary, Person), and 
that the logic expression of "client" is is_client(Person). The corresponding Masque logical 
query would be: 

answer ( [Salary , Person]) :- 
is_client (Person) , 
salary_of (Salary , Person). 

Using predicate-argument constraints, we could specify that the argument of isjdient 
must belong to the class (must be of type) client-class, and that the arguments of salary _of 
must belong to the classes salary_class and employ ee-dass respectively. These constraints 
would require the variable Person in the logical query to belong to both clientjdass and 
employee -class. Since, neither client-class nor employ ee-dass is a descendant of each other 
in the hierarchy of figure the system would be able to reason that the logical query contains a 
class mismatch. The class mismatch could then be reported to the user. In contrast, assuming 
that the logic expression of "technician" is is-technician(Person), where Person is a variable 
of type technician-class, the question "What is the salary of each technician?" will generate 
the Masque logical query: 

answer ( [Salary , Person]) :- 
is_technician(Person) , 
salary_of (Salary , Person). 

In this case, Person is required to belong to technician -class and employee-class. Since 
employ eejdass is an ancestor of (i.e. subsumes) technician-class, the logical query contains 
no class mismatch. 

The predicate-argument constraints can also help the system to resolve natural language 
ambiguities. Consider, for example, the request "List all employees in a company with a 
driving licence" . From the Nlidb's point of view, the request contains a modifier attachment 
ambiguity (see section |4.1| ): "with a driving licence" may refer either to "employees" or to 
"company". In the first MASQUE-like logic query would be: 

answer ( [Employee] ) : - 

is_employee (Employee) , 
is_company (Company) , 
is_drv_licence (Driv_lic) , 
in (Employee, Company), 
has (Employee , Driv_lic) . 

while in the second case ( "with a driving licence" refers to "company"), the logic query would 
look like: 
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answer ( [Employee] ) : - 

is_employee (Employee) , 
is_company (Company) , 
is_drv_licence (Driv_lic) , 
in (Employee, Company), 
has (Company , Driv_lic) . 

The world model could specify that the arguments of is-employee, isjcompany, and 
isjdrv .licence are of types employee-class, company -class, and drv licencejdass respec- 
tively, and that if the second argument of has is of type drvJicence-dass, then the first ar- 
gument must be of type person_class (i.e. only persons are allowed to have driving licences). 
The hierarchy could then be used to state that pcrsonjdass subsumes employecjdass but 
not company -class (i.e. companies are not persons). This would rule out the second logical 
query above, where the second argument of has is of type drvJicence-dass, and the first one 
is not of type person-class. 

The logic query generated by the parsing and semantic interpretation module, expresses 
the meaning of the user's question in terms of logical, high-level concepts. The logic query does 
not refer to database objects (e.g. tables, columns), and it does not specify how to search the 
database to retrieve the necessary information. In order to retrieve the information requested 
by the user, the logic query has to be transformed into a query expressed in some database 
query language supported by the underlying Dbms (Database Management System). In figure 
H this transformation is carried out by the database query generator, using the mapping to 
database information. 

The mapping to database information specifies how logic predicates relate to database 
objects. In the case of an interface to a relational database, the simplest approach would be 
to link each logic predicate to an Sql SELECT statement, selecting rows from one or more 
database tables. Let us assume, for example, that the database contains the tables: 



Let us also consider the Masque logic query for "What is the capital of each country bordering 
Greece?": 

answer ( [Capital , Country] ) : - 
is_country (Country) , 
borders (Country , greece) , 
capital_of (Capital , Country). 

The mapping information could link the predicate is_country to the SQL query: 

SELECT country 

FROM countries_table 

Such linking would mean that is_country is true if its argument appears in the column 
country of countries Jtoble. Similarly, borders could be linked to the SQL query: 



countries-table 
country capital language 



borders_table 
countryl country2 



France Paris French 
Spain Madrid Spanish 
Germany Berlin German 



France Spain 
France Germany 
Germany France 
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SELECT countryl , country2 
FROM borders_table 

which would mean that borders is true if there is a row in borders -table, such the first 
argument of borders is the countryl of the row, and the second argument of borders is the 
countryl of the row. Finally, capital_of could be linked to: 

SELECT capital, country 
FROM countries_table 

A similar (but more complex) approach is used in Masque/sql [|J] |5|. Using the mapping 
information, Masque/sql would generate an SQL query similar to: 

SELECT countries_table . capital , countries_table . country 
FROM countries_table , borders_table 
WHERE countries_table . country = borders_table . countryl 
AND borders_table . country2 = 'Greece' 

The transformation of the logic query to a database query does not need to be made 
in one stage. In 34] p3] pi, for example, the writers describe a principled multi-stage 



transformation process, used in the Nlidb developed at the University of Essex. The Essex 
system first generates a logic query, expressed in a version of untyped A-calculus pq| . The 
A-calculus expression is then transformed into a first-order predicate logic expression, which is 
subsequently translated into universal-domain relational calculus, domain relational calculus, 



tuple relational calculus, and finally Sql (see |98[] for a description of the various forms of 
relational calculus). 

In figure || the database query generated by the database query generator is passed to 
the underlying Dbms, which executes the query against the database, and passes the re- 
trieved data to the response generator. The latter is responsible for reporting the retrieved 
information to the user. Issues related to response generation are discussed in the following 
section. 

In most modern Nlidbs the underlying database is assumed to be relational. Some 
Nlidbs support multiple underlying, possibly heterogeneous, databases (see section f>.6\) . 
Research systems often assume idiosyncratic database models, especially designed to facilitate 
the development of the Nlidb. 

When constructing a new Nlidb, one design issue is the 'division of labour' between 
the Nlidb software and the Dbms's query language. The de facto industry standard query 
language is Sql. As a language, standard Sql is less expressive than a programming language, 
since it lacks constructs for iteration and recursion, amongst other things. Thus there are 
computationally reasonable queries that might be expressed in natural language, but which 
cannot be answered by a single Sql query. Of course, most current Nlidbs support only a 
limited subset of natural language. In many cases, this subset may be so narrow that less 
queries can be expressed in the supported natural language subset than in Sql. The point 
being made here, however, is that full natural language is more expressive than single Sql 
queries. Thus, as the natural language subset supported by the linguistic component grows, 
there will be inevitably natural language queries that cannot be mapped to single Sql queries. 

In such cases, the designer of the Nlidb must choose between either restricting the natural 
language subset to make it match the expressivity of single Sql queries, or allowing a natural 
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language query to be translated into some data-dependent number of Sql queries, and piecing 
together the answer to the original natural language query from the set of answers to the Sql 
queries. Thus the iteration or recursion would have to be controlled from within the Nlidb 
software. 

Developments in Sql are likely to have an impact on the design of Nlidbs. Sql3 has a 
richer set of storage structures, types and querying constructs than Sql. On the one hand, 
this means that more can be done in the Dbms, and less in the Nlidb, but on the other hand, 
broader linguistic coverage will be needed in the Nlidb to ensure that the supported natural 
language subset captures the expressivity of the Dbms's query language. 

One of the advantages of Nlidbs based on intermediate representation languages is that 
the linguistic front- end (the part of the system that generates the logic queries - see figure 
is independent of the underlying Dbms. Thus, the Nlidb can be ported to a different Dbms, 



by rewriting the database query generator module (see section |6.2|) . This approach also allows 
the development of generic linguistic front-ends, that can be used as parts of interfaces to 
systems other than databases (e.g. expert systems, operating systems etc). One example of 
such a generic front-end is the Cle system [EJ. 

Another advantage of the particular architecture shown in figure [5|, is that the domain- 
dependent knowledge (i.e. knowledge that has to be modified whenever the system is used in 
a new knowledge domain - e.g. questions about flights, instead of questions about books in 
a library) is clearly separated from the rest of the front-end, thus allowing knowledge-domain 
portability (see section |Q| ). 

Finally, Nlidbs based on logical intermediate representation languages, allow reasoning 
modules to be added between the semantic interpreter and the database query generator, so 
that the Nlidb can carry out reasoning based on the information stored in the database (see 
section |8|). In systems where the parse tree is mapped directly to an expression in a database 
query language (e.g. Sql), such reasoning would have to be carried out in the database query 
language. This is practically impossible, since database query languages are not designed to 
facilitate machine reasoning. 

5.5 Response generation 



The discussion in section |5,4| focused on the interpretation of the natural language input. 
Generating a suitable response is also important. Some Nlidbs that interface to relational 
databases simply print the tuples retrieved by the database query, an approach which is not 
always acceptable: 

• The retrieved database tuples may contain encoded information (e.g. department codes 
instead of department names). 

• The system may not be able to "understand" the question, in which case no tuples will 
be retrieved. The cause of the failure should be explained to the user (e.g. unknown 
word, syntax too complex, no relevant information in the database, etc). 

• The user's question may contain false presuppositions about the database or the world, 
in which case the system should report the false presuppositions (e.g. "Do all managers 
earning more than 50,000 work in sales?", when no manager earns more than 50,000). 
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• The user's request may not express literally what the user wants to know. For example, 
it may not be acceptable to answer a "yes"/ "no" question (e.g. "Is there a Right to 
Athens?") by a yes/no response. 

To illustrate some of these points, consider the following dialogue between the user and 
Loqui, based on examples from |l4j] and flSfl : 

> Does every person that works on 20 projects work on HOSCOM ? 
There is no such person. 

> Does' David Sedlock work on something? 
Yes. 

Bim_Loqui, Mmi2, Nlpad 

> Does RV work on LOQUI? 

No. RV works on BlM-PROLOG. 

In the first question, the system has detected the false presupposition that there are people 
working on 20 projects, and it has reported a suitable message. (Strictly logically speaking 
the response could have been "yes", since no person works on 20 projects.) In the second 
and third questions, the system did not simply print "yes"/ "no" responses; it also printed 
additional information, that the user probably wanted to know. 

In some cases, such "cooperative responses" (see |64|] |35|]) can be generated by using 
relatively simple mechanisms. For example, in yes/no questions like "Does David Sedlock 
work on something?" , if the answer is affirmative one strategy is to print a "yes", followed by 
the answer to "On what does David Sedlock work?". (It is usually not difficult to generate 
automatically questions like "On what does David Sedlock work?" from questions like "Does 
David Sedlock work on something?".) A description of some relatively simple mechanisms 



that have been used in Masque to generate cooperative responses can be found in [ 33 1 , and 
| |41| gives a more formal account of some of these techniques. 

It is not always possible, however, to generate reasonable cooperative responses by using 
simple mechanisms. In some cases, in order to generate an acceptable cooperative response, 



the Nlidb must be able to reason about the user's goals. This is discussed in section |8.2 . 

Another problem is that the Nlidb may misinterpret a question submitted by the user, 
without the user becoming aware that his/her query has been misinterpreted. Natural lan- 
guage questions often have several readings; the Nlidb may select a reading of a question 
that is different from the reading the user had in mind when he/she typed the question. In 
these cases, it may be hard for the user to understand that the system has actually answered 
a different question. To avoid such misunderstandings, Tqa [31] contains a module that con- 



verts the Sql query back to natural language. The reconstructed natural language request 
is presented to the user, to ensure that none of the intermediate transformation stages has 
caused his/her request to be misinterpreted. Similar paraphrasing modules are used in several 
other Nlidbs. pH] [67] describes how the paraphrasing module of a particular Nlidb works. 



To make the retrieved information easier to read, many Nlidbs contain response format- 
ting modules, that allow encoded information retrieved from the database (e.g. "dpt341") 
to be expanded to more natural formats (e.g. "Sales department"). Finally, some Nlidbs 
(e.g. Natural Language |75|]) can present some kinds of retrieved data in graphics (e.g. 
pie-charts) . 
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5.6 Multiple underlying systems 



The architectures described so far, allow the user to interact with a single database. In some 
cases, however, access to more than one underlying applications may be necessary. 

In certain domains, the information needed to answer the user's question may be dis- 
tributed in several, possibly heterogeneous, databases. (See [22\ for an introduction to dis- 
tributed and heterogeneous databases.) Some Nlidbs (e.g. Intellect according to |)6| ) 
allow the user to access transparently multiple databases through a single English question. 
The Nlidb translates the logic query into a set of database queries, each one expressed in the 
query language of the corresponding Dbms. The Nlidb then collects and joins the partial 
results retrieved by each Dbms, and reports the answer to the user. 

Intellect can be configured to interact with the database through the Kbms |)?]] expert 
system shell. This way a reasoning layer can be added between the Nlidb and the database, 
which allows the Nlidb to carry out reasoning based on the data stored in the database (see 
section |8|) . 

Ask Q |9^] can be configured to interface transparently to several kinds of software 
systems (e.g. electronic mail systems, screen painters, word processors, etc). Ask translates 
each natural language request into a suitable expression, which is then directed to the ap- 
propriate underlying system. This way, the user views an integrated computer system, with 
natural language understanding abilities. 

Janus [|l7]] has the ability to interact with databases, expert systems, decision support 
systems, graphics systems, etc., and all the underlying systems may be involved in the an- 
swering of a user's question. For example (the example is based on (TtJ), when asked "Which 
submarines have the greatest probability of locating A within 10 hours?", the system might 
use a database to retrieve the current positions of the submarines, and two separate expert 
systems to compute (a) the navigation course each submarine would have to follow, and (b) 
the probability of success for each submarine. 



6 Portability 



Early Nlidbs were each designed for a particular database application. Lunar | 106 |, for 
example, was designed to support English questions, referring to a database of a particu- 
lar structure, holding data about moon rocks. Such application-tailored Nlidbs were very 
difficult to port to different applications. In recent years a large part of the research in 
Nlidbs has been devoted to portability, i.e. to the design of Nlidbs that can be used in 
different knowledge-domains, with different underlying Dbmss, or even with different natural 
languages. This section discusses the different kinds of Nlidb portability, and presents some 
methods that have been used to approach the goal of portability. Most of the discussion 
relates to the architecture of figure ||. 



6.1 Knowledge-domain portability 

Existing Nlidbs can only cope with questions referring to a particular knowledge domain 
(e.g. questions about train services, questions about bank accounts). A Nlidb provides 
knowledge-domain portability, if it can be configured for use in a wide variety of knowledge 
domains. 
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Typically, whenever a Nlidb is being reconfigured for a new knowledge-domain, someone 
has to "teach" the system the words and concepts used in the new domain, and how these 
concepts relate to the information stored in the database. In systems adopting architectures 
similar to the one of figure [|, this "teaching" modifies the lexicon, the world model, and the 
mapping to the database. 

Different Nlidbs assume that the knowledge-domain configuration will be carried out by 
people possessing different skills: 



Programmer: In some systems a part (usually small and well defined) of the Nlidb's code 
has to be rewritten during the knowledge domain configuration. It is, therefore, assumed that 
the person that will carry out the configuration will be a programmer, preferably familiar with 
the Nlidb's code. 



Knowledge engineer: Other Nlidbs provide tools that can be used to configure the system 
for a new knowledge domain, without the need to do any programming. It is still assumed, 
however, that the tools will be used by a knowledge engineer, or at least a person familiar 
with basic knowledge representation techniques, databases, and linguistic concepts. 

In the following dialogue, between Masque's "domain editor" |7j and the knowledge 
engineer, the verb "to exceed" (as in "The population of Germany exceeds the population of 
Portugal") is added to the system's knowledge. (Actually, Masque's domain-editor does not 
shield completely the knowledge-engineer from the programming language. The knowledge 
engineer is still required to write some Prolog code to map logic predicates to database 
objects.) 

editor> add verb 

what is your verb ? exceed 

what is its third sing, pres ? exceeds 

what is its past form ? exceeded 

what is its perfect form ? exceeded 

what is its participle form ? exceeding 

to what set does the subject belong ? numeric 

is there a direct object ? yes 

to what set does it belong ? numeric 

is there an indirect object ? no 

is it linked to a complement ? no 

what is its predicate ? greater Jhan 

do you really wish to add this verb? y 

The logic expression of "to exceed" was defined to be greater _ihan{arg\,arg2), where both 
arguments were declared to belong to the hierarchy class numeric (see section I 



Some systems (e.g. Parlance [12], Cle [g]) provide morphology modules, that allow the 
system to determine the various forms of the words using stems stored in the lexicon and 
morphology rules. This way, the user does not have to specify all the word forms as in the ex- 
ample above ( "exceed", "exceeds", "exceeded", "exceeding" , etc) . This ability is particularly 
important in highly-inflected languages, where each word may have numerous possible forms. 
Some systems (e.g. Natural Language [75], Cle Q) have built-in dictionaries, listing 
the most common words. The dictionaries can be customised by the person configuring the 
system to include domain-specific terminology. 
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DB administrator: According to the designers of Team [|47| |48|], a realistic scenario is 
to assume that the Nlidb will be bought by a company already using a database to which 
the Nlidb is to be linked. In such situations, the responsibility of installing and configuring 
the Nlidb would probably be assigned to the local database administrator. Therefore, the 
configuration tools should be designed, so that they can be used by persons with a good 
understanding of database concepts, familiar with the particular database to which the Nlidb 
is to be linked, but with no knowledge of AI, logics, or linguistics. Team tries to infer what 
questions can be asked about the database, by eliciting from the database administrator 
information about the use and structure of the database. 

In the following dialogue (from [47] - slightly simplified), the system collects information 



about the structure and use of the database table ("file") CHIP. (The reader is reminded 
that messages generated by the system are shown in this typeface, and user entries are 
shown in this typeface.) 

file name: CHIP 

fields : ID MAKER WIDTH . . . 

subject: processor 

synonyms for processor: chip 

primary key: ID 

Can one say ' 'Who are the processors?': no 
Pronouns for subject (he, she, it, they): it 
field: MAKER 

type of field (symbolic, arithmetic, feature): symbolic 

The user is asked to provide information about the table's fields (attributes), the subjects 
the table describes ("processor"), etc. The dialogue would then continue with the system 
asking several questions for each field of CHIP. The reader will have noticed that the sys- 
tem's questions do not refer to logic concepts (e.g. hierarchy classes, predicates) or advanced 
linguistic concepts, although they contain database terminology (e.g. "primary key"). 

End-user: Other Nlidb designers emphasise that the configuration phase can never be 
complete, and that the Nlidb will always have to learn new words and concepts. Therefore, 
the Nlidb should allow the end-users to teach the system on-line, and using definitions 
expressed in natural language. Systems adopting this approach usually have a large built-in 
vocabulary, and a set of primitive concepts (meanings). The end-user can extend the system's 
capabilities by teaching it new words, and by defining the meanings of the new words in terms 
of primitive concepts or in terms of words the system already knows. 



The following examples from [12] show some of the capabilities of Parlance: 

> define: a yuppie is a person under 30 with a graduate degree who 
earns over 5K per month 

> define: a rich employee is an employee who earns over 100K per year 

6.2 DBMS portability 

A Nlidb provides DBMS portability, if it can be easily modified to be used with different 
underlying database management systems (Dbmss). 
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In the case of Nlidbs that generate queries in widely-supported database query languages 
(e.g. Sql), it may be possible to port the Nlidb to another Dbms, with only minor modifi- 
cations, if the new DBMS supports the same database query language as the old one. 

If the original database query language is not supported by the new Dbms, then a Nlidb 
based on the architecture of figure [| can be ported to the new DBMS by rewriting the module 
that translates the intermediate logic queries to database queries. In contrast, Nlidbs that 
do not use intermediate representation languages may require extensive modifications before 
they can be used with a new Dbms that does not support the old database query language. 

In the case of Nlidbs that clearly separate the linguistic front-end (see figure |5|) from the 
rest of the system, it should be possible to port a Nlidb configured for a particular knowledge- 
domain to a different underlying Dbms containing data about the same knowledge-domain, 
without modifying the modules of the linguistic front-end. 



6.3 Natural language portability 

The largest part of the research that has been carried out in the area of Nlidbs assumes that 
the natural language requests will be written in English. Modifying an existing Nlidb to be 
used with a different natural language can be a difficult task, since the Nlidb may contain 
deeply embedded assumptions about the natural language to be used. 

In Nlidbs based on the architecture of figure & modifying the Nlidb for a different 
natural language typically requires rewriting/modifying the syntax rules, the semantic rules, 



and the lexicon. An attempt to build a Portuguese version of Chat-80 [101] is described in 
36|. Information about a Swedish version of Cle can be found in 0. 



6.4 Hardware and programming language portability 

Up to the early eighties, the ability to port the Nlidb to different hardware and software 
environments were also important aspects of Nlidbs. Some Nlidbs could be used only on 
expensive research computing systems, supporting "exotic" programming languages (e.g. Lisp 
machines), thus making Nlidbs almost impossible to use in real-life applications. In recent 
years the availability of powerful low-cost computers and the fact that "AI" languages like 
Prolog and Lisp are now commonly available have allowed Nlidbs to become easy to port 
across computing platforms. 



7 Restricted NL input 

Current Nlidbs support only a limited subset of natural language. The limits of this subset 
are usually not obvious to the user (see section ||). Users are often forced to rephrase their 
questions, until a form the system can understand is reached. In other cases, users never try 
questions the Nlidb could in principle handle, because they think the questions are outside 
the subset of natural language supported by the Nlidb. 

Many research projects attempt to expand the linguistic coverage of Nlidbs, hoping that 
eventually Nlidbs will be able to understand most user requests, at least in particular knowl- 
edge domains. An alternative approach, presented in this section, is to deliberately and 
explicitly restrict the set of natural language expressions the user is allowed to input, so that 
the limits of this subset are obvious to the user. By choosing carefully the subset of the 
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allowed natural language expressions, the design and implementation of the Nlidb can also 
be simplified. 

This section presents two approaches that drastically restrict the set of natural language 
expressions the user is allowed to input. In the first one, only questions of a very specific 
syntactic pattern are allowed; in the second one, the user has to compose his/her queries by 
choosing words from limited lists of words displayed on the screen. 

7.1 Restricted NL syntax 

In Pre [[5]] the user is allowed to input only questions of a specific syntactic pattern. All 
questions must have the form: 

what 

conjoined noun phrases 
nested relative clauses 
conjoined relative clauses 



The following question (from [4G| — simplified) is an example of a question acceptable by Pre: 



what are 

the names, ids, and categories of the employees (1) 

who are assigned schedules (2) 

that include appointments (3) 

that are executions of orders (4) 

whose addresses contain c maple' and (5) 

whose dates are later than 12/15/83 and (6) 

whose statuses are other than 'comp' (7) 

In the example above, line (1) contains the conjoined noun phrases. Lines (2)-(4) contain 
the nested relative clauses. Notice that these clauses are nested, because (3) refers to "sched- 
ules" in (2), and (4) refers to "appointments" in (3). Lines (5)— (7) contain the conjoined 
relative clauses. The clauses in (5)— (7) are not nested; they all refer to "orders" in (4). 
In contrast, the following question is not acceptable by Pre: 

what are 

the addresses of the appointments (1) 

that are included in schedules (2) 

whose call times are before 11:30 and (3) 

that are executions of orders (4) 

whose statuses are other than 'comp' (5) 

In the latter example, line (2) contains the only clause of the nested relative clauses part. 
Both (3) and (4) are conjoined relative clauses referring to "schedules" in (2). However, (5) 
is nested with respect to (4), since it refers to "orders" in (4), not to "schedules" in (2). The 
Pre question pattern does not allow the conjoined relative clauses part to be followed by 
another nested relative clauses part, and hence the question is ill-formed. 

pof claims that the Pre question pattern allows the users to have a clear view of the 
questions the system is able to answer, and that the pattern is easy to remember. The Pre 
question pattern is designed to facilitate the mapping from user questions to navigation graphs 
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Figure 7: A PRE-like database schema 



for Pre's entity-relationship-like |9^] database model. Figure |7| shows the database schema 
to which the above two examples refer. (The schema of figure may not have exactly the 
same form as the schemata used in Pre.) Oval boxes correspond to entity classes, rectangular 
boxes correspond to attributes, and continuous lines correspond to relations. 

• The conjoined noun phrases part of each Pre question corresponds to a projection oper- 
ator, similar to the ones used in relational algebra J98|| . Projection operators determine 
the attributes of an entity to be reported. 

• The nested relative clauses part corresponds to traversals of continuous line links in the 
Pre model. 

• The conjoined relative clauses part corresponds to select operators, similar to the ones 
used in relational algebra. A select operator selects entities from an entity class, ac- 
cording to some criteria. 

To answer the question of the first example in this section, Pre first transforms the 
conjoined relative clauses part of the question to a select operator, that selects all entities 
from class order, containing "maple" in their addresses, having dates later than 12/15/83, 
and having statuses other than "comp". 

Next, Pre transforms the nested relative clauses part of the question to a sequence of 
relation (continuous line) traversals. In the case of our example, the nested relative clauses are 
mapped to a sequence of traversals, mapping orders to appointments via the execution_of 
relation, appointments to schedules via the includes relation, and schedules to employees 
via the assigned_a relation. 

Finally, Pre transforms the conjoined noun phrases part of the question to a projection 
operator. For each employee entity reached during the previous step, the system reports its 
name, id, and category. 

7.2 Menu-based systems 

In menu-based systems the user is not able to type directly his/her questions. Instead, each 
question has to be constructed by choosing possible words or phrases from menus. The menus 
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Figure 8: The initial screen of Nlmenu 



are displayed on the screen, and they are continuously updated. This method, used in the 
Nlmenu system |M| |Jl]] , will be illustrated by examples from |9lJ . Q&A (section ^) provides 
a similar menu-based interface. 

Nlmenu first displays a screen like the one shown in figure [8|. (The actual Nlmenu screens 
are slightly more complicated.) Highlighted borders indicate menus that are currently active. 



The user first selects "Find". (Nlmenu also has update capabilities - see section 9.1 - which 
will not be discussed in this paper.) "Find" becomes the first word of the user's question, 
and it is displayed in the lower part of the screen. After "Find" has been selected, the 
attributes, nouns, and connectors menus become activated. The user selects "color" from 
the attributes menu, and the question becomes "Find color". In a similar manner, the user 
then selects "and", "name", "of", and "parts". At this stage the Nlmenu screen has become 
as shown in figure [|. (After selecting each word, the contents of the menus are modified.) 

The user selects "whose color is" from the modifiers menu, and the question becomes 
"Find color and name of parts whose color is". At this point, a special menu appears on screen, 
listing the possible colors. After selecting a color (e.g. "red"), the question is complete. The 
user executes the query by selecting an option on the screen, and the system reports the 
results retrieved from the database. 



Nlmenu uses a context-free semantic grammar (see section Whenever a new word or 
phrase is selected, the system parses the sentence assembled so far, and processes the grammar 
to determine the words/phrases that can be attached to the existing partial sentence to form 
a sentence the system can understand. These words/phrases are then shown in the active 
menus. This way, only sentences the system can understand can be input, and the user can 
browse through the menus to explore the kinds of questions the system can handle. 

Although a new semantic grammar is needed for each new knowledge domain (see section 
^), Nlmenu grammars do not have to cope with a large number of possible user sentences. 
The menus can be used to greatly restrict the kinds of sentences the user can input, and 
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Figure 9: The Nlmenu screen after several more words have been selected 



hence the semantic grammars of Nlmenu are relatively simple to write. According to [91], 
Nlmenu is typically customised for a new application in 1 - 30 man-hours. 

The menu-based approach guarantees that the user's input is free from spelling errors, 
and allows user queries to be input using a simple pointing device. However, as mentioned in 
[91], in applications requiring long questions menu-searching can become tedious. 



8 NLIDBs as intelligent agents 

Most Nlidbs described so far are direct interfaces to the underlying database, in the sense 
that they simply translate user questions to suitable database queries. The database is seen as 
the only source of information about the world. (The Nlidb itself only contains a simplistic 



world-model - section 5.4). This section will discuss Nlidbs that contain knowledge about 
the surrounding world and about the user. This knowledge allows them to handle questions 
that cannot be answered directly by the Dbms, and to understand better the user's goals. 



8.1 Reasoning about the world 

In some cases it may not be possible to answer a natural language question, although all the 
necessary raw data are present in the database. Questions involving common sense or domain 
expertise are typical examples. In these cases, the answer to the question is not explicitly 
stored in the database; to produce the answer, the Nlidb must be able to carry out reasoning 
based on the data stored in the database. 

Let us assume, for example, that the database holds the medical records af all patients 
in a hospital (e.g. the names of the patients, their ages, diagnoses made for each patient, 
treatments the patients have received, etc.), and let us assume that the Nlidb is asked 
"Which patients are likely to develop lung disease?". Let us also assume that the database 
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Figure 10: Architecture of a Nlidb with a reasoning module 



does not show explicitly how probable it is for each patient to develop each disease (i.e. these 
probabilities are not stored in the database). In this case the Nlidb will not be able to answer 
the question, unless it is told how to use the medical data in the database to determine how 
probable it is for each patient to develop lung disease. In other words, the Nlidb must have 
access to domain expertise (in this case medical expertise, perhaps in the form of rules), 
showing how to carry out reasoning based on the raw data in the database. 

The architecture of figure [5| can be extended to allow the Nlidb to carry out reasoning 
based on the data in the database. One possible extension, exemplified by Loqui |l5|], is to 



add a rule-based reasoning module on top of the database as shown in figure 1C. 



Systems adopting the architecture of figure 10 still transform the natural language question 



into a logic query that captures the meaning of the question, as discussed in section |5.4| . When 
asked "Which patients are likely to develop lung disease?", such a system could generate the 
logic query (variables start with capital letters): 

report Patient such that: 
is_patient (Patient) and 

likely_to_develop (Patient , lung_disease) 

Some of the predicates in the logic queries may be linked directly to tables in the database, 
as discussed in section |5.4f For example, is-patient(Patient) could be linked to a database 
table patients listing all the patients in the hospital. Thus, isjpatient{Patient) would be 
true if patients showed that Patient is a patient in the hospital. 

For predicates not directly linked to database tables, suitable rules must be present in the 
rule-base, showing how to evaluate instances of these predicates. Continuing with the same 
example, the rule-base could contain the rule: 

likely _to_develop (Patient , Disease) if 
prob (develop (Patient , Disease)) > 0.7 

The rule above says that a patient is likely to develop a disease if the probability of the patient 
developing the disease is greater than 0.7 

Other rules would show how to use the data in the database to assess the probability of 
a patient developing a disease. For example: 
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if has (Patient , blood_disease) then 

prob (develop (Patient , lung_disease) ) = 0.6 

if is_smoker (Patient) then 

prob (develop (Patient , lung_disease) ) = 0.7 

Finally, other rules would show how to combine the probabilities predicted by the rules above, 
in cases where more than one rules apply (e.g. patient with blood disease who is also a smoker). 
(See for an introduction to rule-based reasoning with probabilities.) 

In Loqui, according to [14|, both the logic queries and the rules of the rule-base are 



expressed in Prolog. The logic query is treated as a Prolog goal to be evaluated by the Prolog 
interpreter, and rows in the database tables are treated as Prolog facts. (See for example 



| 70| plf [PQ1 |39|| for information on how Prolog can be linked to external databases.) Thus, 
the full power of Prolog is available when evaluating a query, or when defining the rules in 
the rule-base, and the internal Prolog database can be used to hold knowledge about the 



world that cannot be easily encoded in the external relational database. Chat-80 [ 101 1 and 
Masque || M offer similar capabilities. 



Intellect, according to [p6[ , can be configured to use the Kbms [97] expert system shell 
as its reasoning module. The logic query is passed to Kbms, and it is the responsibility of 
Kbms to find all the possible answers using its specialised inferencing techniques and the 
facts stored in the external database. This way, the full power of the expert system shell 
(e.g. forward chaining, backward chaining, hypothetical reasoning, etc.) is available when 
evaluating the logic query, and the shell's tools can be used to develop the rule-base. The 
natural language capabilities of Intellect can be used to define Kbms rules. For example 



[97], a Kbms rule can be entered as £ TF the customer has an overdue balance outstanding, 
Then credit risk is high". Natural language questions can also query the shell's reasoning. 
For example, "Why was the application of Smith rejected?" would cause the system to report 
the steps it took to reject Smith's application. 

Perhaps the reasoning module should not be considered part of the Nlidb, but rather an 
independent layer on top of the database system (or a component of an "expert database" 
system). A strong argument in favour of this view is that the ability to carry out reasoning 
on top of the database is not needed only in Nlidbs. A graphical interface would also need 
to access the reasoning module in order to answer a graphical query corresponding to "Which 
patients are likely to develop lung disease?". The reasoning module should not, therefore, be 
part of the Nlidb 's code. It should be an independent module, available to any application 
that may need it. 

8.2 Reasoning about the user's goals 

User requests often do not express literally what the user wants to know. Let us consider the 



following dialogue, based on an example from [63]: 

> Do American Airlines have a night Eight to Dallas? 
yes 

It would be better if the system could respond: 
Yes, flight 712. 
or: 

No, but United have flight 655. 
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In the case of the last two responses, instead of simply printing a yes/no response, the Nlidb 
has also reported additional information that the user would probably be interested to know. 
Notice that in the last response an alternative United flight was reported, even though the 
user had requested an American Airlines flight. 



As already mentioned in section 5.5, in some cases reasonably cooperative responses can 
be generated by using relatively simple mechanisms. For example, in yes/no questions like 
"Do American Airlines have a night Eight to Dallas?", if the answer is negative, the Nlidb 
could report a "no" , along with the answer to a "weaker" question like "Does a carrier have a 
night Eight to Dallas?". The weaker question is generated from the original one by removing 
one restriction (the restriction that the carrier must be American Airlines in our example). 
(A similar but more elaborate method is proposed in |5fJ.) 

Unfortunately, simple strategies, like dropping an arbitrary restriction, do not always 



generate acceptable responses. As pointed out in [63], the previous dialogue could have been: 

> Do American Airlines have a night Eight to Dallas? 
No, but they have one to Miami. 

In the latter dialogue the system has dropped the restriction that the flight must go to 
Dallas, rather than the restriction that the carrier must be American Airlines. The resulting 
"cooperative" response would probably be irritating for the user. To avoid such inappropriate 
responses, the Nlidb must be able to "understand" the user's goals. (This is often called 
"plan recognition" in the literature - see for example ||].) In the previous question, we would 
like the Nlidb to be able to understand that the user's goal is to go to Dallas, and that 
therefore it would be inappropriate to report a flight to Miami. 

This could be achieved by having a rule stating that when a person asks about a flight to 
a particular location, the goal of the person is probably to reach that location. Another rule 
could state that if the person has specified a particular carrier, then flying with that carrier is 
probably a preference but not a goal. Finally, another rule could state that if it is not possible 
to satisfy all goals and preferences, then preferences, but not goals, can be dropped. Hence, 
in "Do American Airlines have a night Eight to Dallas?", if there is no American Airlines 
night flight to Dallas, the system would drop the carrier constraint, and not the destination 
constraint. 

The reasoning about the user's goals could be carried out by reasoning modules similar 
to the ones described in the previous section (figure |K]). In this case, however, the rule-base 
would contain rules explaining how the user's requests relate to his/her goals, and what to 
do to satisfy the user's goals. The user's request would be mapped to a logic query, and the 
logic query would be passed to the reasoning module. The reasoning module would then try 
to satisfy the user by reasoning about his/her goals, and by retrieving information from the 
database. 

The rules in the rule-base can be thought as constituting a model of the user, a logic 
system describing how user utterances relate to the user's intentions and beliefs. The need 
for elaborate user models becomes essential in dialogue systems, discussed in the following 
section. 

8.3 Dialogue systems 

The architectures discussed so far focus on the understanding of individual user questions. 
The parsing and semantic interpretation modules form the backbone of the system, while 
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Figure 11: Possible architecture of a dialogue-oriented system 



reasoning and response generation modules are treated as peripheral accessories. In other 
words, it is the processing of each individual question that drives the system's behaviour. 

In dialogue-oriented systems the system's behaviour is driven by a reasoning module, 
which reasons about the goals and beliefs of both the user and the system. A possible 
architecture of a dialogue-oriented system is shown in figu re |iT| . (The architecture shown is 
greatly influenced by the Ir-nli architecture described in [49].) 



The central module of the architecture in figure 11 is the dialogue controller. The dialogue 



controller is a reasoning module, whose purpose is to understand the user's needs and to 
convey the relevant information to the user. The dialogue controller consults a rule-base, 
that contains rules explaining how to carry out a dialogue. For example, the following is a 
simplified dialogue-control rule for Wisber [44], a natural language consultation system: 



(want system 

(know system X)) A 
(believe system 

(know user (related X))) A 
->(know system 

->(know userX)) 



(ask 
system 
user 
X) 



(know mutual 
(want system 
(know system X))) A 
(know mutual 
(believe system 
(know user (related X)))) 



The rule says that if: 

• the system wants to know a piece of knowledge, called X, and 

• the system believes that the user knows something related to X, and 

• the system does not know that the user does not know X 

then, the system should ask the user about X, and after the question has been asked, the 
system should assume that: 



both the system and the user know that the system wants to learn X, and 
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both the system and the user know that the system believes the user knows something 
related to X. 



In figure 11 the current state of discourse contains facts describing the current goals and 
beliefs of the system, and facts describing what the system currently understands to be the 
goals and beliefs of the user. 

Both the natural language interpretation and natural language generation modules are 
subordinate to the dialogue controller. Whenever the dialogue controller wishes to commu- 
nicate information to the user (e.g. ask the user a question, report retrieved information), it 
formulates a logic expression that captures the meaning of the message to be generated. The 
logic expression is then passed to the natural language generation module, which transforms 
it into a natural language message. The natural language interpretation module is then used 
to transform the user's response to a logic expression, and this logic expression is passed to 
the dialogue controller. 

Finally, whenever the dialogue controller wishes to retrieve information about the world, 
it formulates a logic query which is passed to the reasoning about the world module. The 
latter uses the rules to reason about the world to carry out reasoning based on the data stored 
in the external database (as discussed in section |8.1|) . 



In dialogue-oriented systems, the generation of the system's messages (see section 5.5 ) 
is equally important to the interpretation of the user's input. The system's messages must 
be carefully chosen, to guide the dialogue towards areas that will clarify the user's goals 
and beliefs. The system's messages must also reflect correctly its understanding and its 
capabilities. 

9 Further Topics 

This section highlights some areas of Nlidb research that have been less explored, namely 
database updates, meta-knowledge questions, temporal questions, and multi-modal interfaces. 

9.1 Database updates 

Although in several Nlidbs the user is allowed to update the interface's linguistic knowledge 
using natural language requests (section |6TT|) , few systems support natural language requests 
to update the underlying database. Database updates by natural language introduce several 
new problems, which will be illustrated in this section. 



In Ask [pj| [92| update requests can appear at any point during the dialogue with the 



system. The following dialogue is based on examples from [93] [92]: 

> What is the home port of the Tokyo Maru? 
Yokohama 

> Home port of the Tokyo Maru is Hong Kong. 

Yokohama has been replaced by Hong Kong as home port of Tokyo Maru. 

> The cargo of the Tokyo Maru is coal. 
Coal has been added as the cargo of 
Tokyo Maru. 

> What is the cargo of the Tokyo Maru ? 
Grain 

Coal 
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Ask knows that each ship may only have one home port. Therefore, when informed that 
"Home port of the Tokyo Maru is Hong Kong.", it replaces "Yokohama" (previously known 
to be the home port of the Tokyo Maru) by "Hong Kong". In contrast, a ship may carry 
more than one kinds of cargo. Thus, when informed that "The cargo of the Tokyo Maru is 
coal.", Ask adds "Coal" to the kinds of cargo already known to be carried by the Tokyo Maru 
("Grain"). 

Unfortunately, satisfying a natural language update request is not always that straight- 
forward. As explained in [32], natural language update requests often cannot be satisfied, or 
they are ambiguous, or they lead to unanticipated side-effects, due to database constraints 
the user is not aware of. Consider a database containing the following tables (the example is 
borrowed from |32]| ): 

departments_table 
department manager 



employees_table 
employee salary department 



Adams 
White 
Brown 
Smith 



3000 
3500 
2500 
2500 



inventory 
marketing 
sales 
sales 



sales Jones 
marketing Baker 
inventory Fisher 



The following dialogue takes place: 

> List the employees and their managers. 
employee manager 



Adams 
White 
Brown 
Smith 



Fisher 
Baker 
Jones 
Jones 



> Change Brown's manager from Jones to Baker. 
Done . 

> List the employees and their managers. 
employee manager 



Adams 
White 
Brown 
Smith 



Fisher 
Baker 
Baker 
Baker 



Notice that Smith's manager has also changed from Jones to Baker, although this was not 
requested. To a user not aware of the database's structure, such a behaviour would appear 
erratic. The user does not know that in the database employees are linked to managers 
through their departments. Since Brown works in the sales department, the system has 
changed the sales manager from Jones to Baker, which has also caused other employees in 
the sales department (e.g. Smith) to get a new manager. 

Because of the indirect link between employees and managers, the update request is ac- 
tually ambiguous. Instead of changing the sales manager from Jones to Baker, the system 
could have moved Smith from the sales department (managed by Jones) to the marketing 
department (managed by Baker). 

Piquet ]32|] maintains a connection graph, which models the user's view of the database 
structure. Whenever a user utterance reflects awareness or presupposition of a database ob- 
ject, link, restriction etc., the graph is modified accordingly. Every time an ambiguous update 
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request is encountered, the system consults the connection graph to determine which of the 
possible interpretations of the update request are meaningful with respect to the user's current 
view of the underlying database. It then ranks the remaining candidate interpretations, using 
a set of heuristic rules. For example, interpretations causing fewer side-effects with respect 
to the user's view are preferred. Returning to the dialogue above, after "List the employees 
and their managers." has been answered, the user's view of the database is equivalent to a 
table of the form: 

employee manager 



Adams Fisher 

White Baker 

Brown Jones 

Smith Jones 



If the system interprets the request "Change Brown 's manager from Jones to Baker. " as a 
request to change the sales manager from Jones to Baker, then the user's view of the database 
becomes as shown below on the left. (Side-effects are shown in this typeface.) 

employee manager employee manager 



Adams Fisher Adams Fisher 

White Baker White Baker 

Brown Baker Brown Baker 

Smith Baker Smith Jones 

If the system interprets the request as a request to move Brown from the sales department 
(managed by Jones) to the marketing department (managed by Baker), then the user's view 
of the database becomes as shown above on the right. The second interpretation causes no 
side-effects to the user's view, and thus it would have been preferred by Piquet's heuristics. 

9.2 Meta-knowledge questions 

Meta-knowledge questions are questions referring to knowledge about knowledge. For exam- 
ple, some meta-knowledge questions could be |>7]] 

> What information is in the database? 

> What is known about ships? 

> What are the possible employee job titles? 

> Can you handle relative clauses? 



The following example [92] shows how Ask reacts to one meta-knowledge question: 
> What is known about ships? 

Some are in the following classes: navy, freighter, tanker 
All have the following attributes: destination, home port 

An interesting kind of meta-knowledge questions are modal questions. In modal questions 
the user asks whether something can or must be the case. For example: 

> Can a female employee work in sales? 

> Can an employee earn more than his manager? 

> Is it true that all candidates must be over 20? 



In [68] the authors present a method for handling modal questions in Nlidbs to relational 



databases. This method is used in the Nlidb developed at Essex University [34] [33] 
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9.3 Temporal questions 

Most Nlidbs were designed to interface to snapshot databases. Snapshot databases only 
store information about one state of the world, usually taken to be the "present" state. 
Consequently, most Nlidbs only support questions referring to the present state of the world. 
For example, a Nlidb to a company's database would typically be able to answer questions 
like: 

> Who is the manager of the sales department? 

> What is the maximum manager salary? 

but would usually not support temporal questions referring to the past (or the future): 

> Who was the previous manager of the sales department? 

> What was the maximum manager salary during the last 10 years? 

> While Smith was sales manager, did the annual sales income ever exceed 
1 million? 



Most Nlidbs cannot answer temporal questions because: (a) they cannot cope with the 
semantics of natural language temporal expressions (e.g. tenses/aspects, temporal subordina- 
tors), and (b) they were designed to interface to "snapshot" databases, that do not facilitate 
the manipulation of time-dependent information. 

In the last decade, computer scientists have become increasingly interested in temporal 
database systems, i.e. database systems designed to store information about previous or future 
states of the world, and to generally support the notion of time. (The reader is referred to |88| 
for an introduction to temporal databases.) Clifford 24] [25] p3| , Hafner [51], and Hinrichs 
[59] are among those who have considered natural language interfaces to temporal databases.pl 



9.4 Multimodal interfaces 

As discussed in section |3|, form-based interfaces and graphical interfaces appear to have (at 
least some) advantages over natural language interfaces. Some systems attempt to merge 
natural language with graphics, menus, and forms, to combine the strengths of all modalities. 

In Janus []l^| the user is allowed to combine text, menus, graphics, and speech when form- 
ing his/her queries. A user could, for example, type the question "Which of those submarines 
has the greatest probability of locating A within 10 hours?", and then use the mouse and a 
screen displaying the positions of ships to determine the set of ships to which "those" refers. 

One way to integrate natural language and other modalities is exemplified by Shoptalk 



[28]. Shoptalk is actually a complex manufacturing information and decision support system 
with multimodal input capabilities, rather than a simple Nlidb. The methods, however, used 
in Shoptalk could also be used in simple Nlidbs. The following examples are all borrowed 
from |||. 

Shoptalk initially displays a set of menus, listing the available kinds of actions and 
queries (e.g. move a lot, put an object etc). This way, the user has a clear view of the 
system's capabilities. When an action/query- type has been selected, Shoptalk displays a 
form containing fields that have to be filled in. For example, if the user selects the move_lots 
action, the system displays the form: 



The authors are also currently involved in research on natural language interfaces to temporal databases. 
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move_lots 



which lots: 

to which station: 

whenever : 



Each field can be filled using input in the form of any modality supported by Shoptalk. 
For example, the which lots field could be filled by selecting lots from a diagram displayed 
on screen, or by typing natural language. The form above, could be filled as follows (<here> 
denotes pointing with the mouse): 



move_lots 
which lots: each baked lot 

to which station: the manual inspection station 

with the smallest queue 
whenever: it has been moved <here> 



By allowing both natural language and mouse-pointing, the user can combine the strengths 
of both modalities. In the case of the which lots field, the user has chosen natural language 
("each baked lot"), which allows universal quantification ("each") to be expressed easily. It 
would be difficult to express universal quantification using graphics and the mouse: the system 
would have to display all the baked lots, and the user would have to select all the baked lots 
from the display using the mouse. 

Similarly, natural language allows "the manual inspection station with the smallest queue" 
to be expressed easily and concisely. Without natural language support, the user would 
probably have to use a formal specification language, or to use numerous nested menus. 
In contrast, in the case of the whenever field, the user has substituted part of the natural 
language expression by a pointing action on a diagram, thus avoiding the need to provide a 
lengthy natural language description of the location. 

The form-filling approach used in Shoptalk also by-passes some kinds of natural language 
ambiguity. In the following simplified example from [^q] . 

put 

object : the block in the box 

destination: on the table in the corner 



it is clear to the system that "in the box" is a modifier of "the block", that "in the corner" 
is a modifier of "the table", and that "on the table in the corner" is the description of the 
destination and not, for example, a modifier of the object to be moved (see section 4.1 for a 
description of the modifier attachment problem). 

After each question, Shoptalk graphically displays objects to which anaphoric expres- 
sions (e.g. pronouns - see section |4.5| ) of follow-up questions may refer. The user can subse- 
quently deactivate some of these possible referents by pointing on their graphical representa- 
tions, thus reducing the number of possible referents the system has to consider in follow-up 
questions. 

Shoptalk also displays a graphical representation of the discourse structure, allowing the 
user to specify the context to which follow up questions refer. Figure 12 shows a modified 
example from f28[| . The user has specified that both "Which of them were baked before lot3?" 
and "Where were they when lot3 was being baked?" are follow-up questions to "Which lots 
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Which of them were 
baked before lot3 ? 

Which lots are hot? <i 

Where were they when 
lot3 was being baked? 

Figure 12: A context graph in Shoptalk 



are hot?". Therefore, the pronoun "they" in "Where were they when lot3 was being baked?" 
refers to the hot lots, not to the hot lots that were baked before lot3. 

Finally, Shoptalk supports questions referring to past events or states. The user is 
allowed to specify the previous time to which a query refers by either dragging a "time- 
slider", or by filling special when fields (see |2£| for more details). 

10 The state of the art 

This paper has attempted to serve two purposes: to introduce the reader to the field of Nlidbs 
by describing some of the central issues, and to indicate the current situation in this area by 
outlining the facilities and methods of typical implemented systems. The goal of surveying 
the field can be achieved only incompletely at any given moment. Nevertheless, our summary 
here is sufficient to give rise to some general observations about recent work on Nlidbs. 

We have not dealt in detail with the evaluation of Nlidbs. This is a complex problem. 
It is difficult enough to formulate general quantitative (or subtle qualitative) measures of the 
effectiveness of parsers (i.e. programs which extract syntactic information from sentences); 
when we have to consider an entire system, involving semantics, querying, response generation, 
and user interfacing, the situation is much more complicated. Hence, no standard benchmarks 



have yet been developed (see [78] for some discussion). Under these circumstances, any 
appraisal of the current state of the field must be impressionistic and subjective. 

In order to structure our presentation round issues, we have deliberately overlooked one 
dimension of distinction which might be held to be important, namely, the extent to which 
the systems are experimental research vehicles or working commercial applications. The 
majority of the systems we have referred to are oriented more towards exploration of possible 
techniques than towards the production of marketable products. Those which seem to fall into 
the category of experimental prototypes include Lunar, Chat-80, Masque, Team, Ask, 
Eufid, Ldc, Tqa, and others, while Intellect, Parlance, Languageaccess, Q&A, 
Natural Language, Loqui, and English Wizard are actual products or systems used in 
real applications. 

In the context of these caveats, the following observations seem to us to be valid: 

1. There are several facets of Nlidbs (e.g. dictionaries, parsing) where there has been a 
great deal of research and development, and where practical system modules can be 
constructed fairly straightforwardly. 

2. Even in the relatively well-understood subareas mentioned above, there is not a single 
agreed consensus theory or technique. In the other aspects of Nlidbs, there are several 
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difficult theoretical problems which remain to be solved before Nlidbs will be fully 
useful and easily constructed. 

3. The development of Nlidbs is no longer as fashionable a topic within academic research 
as it was in the 1980s. 

4. Although there are several commercially available systems which purport to allow query- 
ing of databases in English, it must be remembered that this claim is flexible in its 
possible interpretations^] These systems may be extremely effective tools for database 
access, and may use some form of English (or other natural languages). This does not 
mean that the problem of completely unrestricted use of natural language queries has 
been solved. 

5. Interfaces which solely use keyboard input of natural language are not likely to be hugely 
practical; in the long term, the use of spoken input, and/or integration with graphical 
user interfaces, are more likely to be the route to practical success. However, keyboard- 
based Nlidbs are still a useful testbed for developing the necessary techniques (e.g. 
semantic interpretation) for subsequent incorporation into these more complex systems. 
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